\chapter{Conclusioni e sviluppi}

\section{Osservazioni conclusive}

Realizzare un'implementazione del linguaggio ci ha permesso di analizzare
approfonditamente la semantica formale definita per Blite e di capire quali
aspetti di essa risultassero particolarmente critici in fase di implementazione
e, più in generale, ci ha permesso di fare alcune riflessioni su BPEL e
sul significato di alcune sue funzionalità.
\\

Il lavoro svolto in questa tesi non è da considerarsi esaustivo, 
ma vorrebbe essere solamente l'inizio di un procedimento iterativo, il cui fine
dovrebbe essere quello di ottenere uno strumento funzionale per
l'orchestrazione di servizi, con una semantica rigorosa da cui sia possibile
ricavare implementazioni coerenti. 

In particolare abbiamo capito che un linguaggio per l'orchestrazione di servizi,
come BPEL, risulta essere uno strumento molto complesso e per questo
riuscirne a sintetizzare gli aspetti cruciali in una semantica formale è
veramente un'attività delicata. Contemporaneamente, sviluppare un'
implementazione di tale semantica, in rispetto dei requisiti che ci possono
essere in sistemi di produzione, non è da meno complicato. 

Per questo può essere utile che le varie attività trovino sostegno reciproco.
Come l'implementazione è guidata dalla semantica, così può essere utile che
l'esperienza ricavata dal processo di sviluppo ritorni nella fase di specifica
formale per apportare eventualmente revisioni e migliorie, e così
iterativamente fino al raggiungimento di un accettabile grado di funzionalità.
\\

% Realizzando l'implementazione abbiamo capito che potrebbe essere interessante
% a livello formale porre più enfasi sul sistema di correlazione, al fine di
% ridurre al minimo i conflitti che si possano creare nell'attribuzione dei
% messaggi alle diverse istanze di processo. 
% 
% In particolare potrebbe valere la pena di svincolare lo stato della correlazione
% dallo stato interno della memoria dei processi e di associarlo solamente alla
% comunicazione dell'informazione.

%Per esempio 
Un punto molto critico dell'implementazione della semantica formale è stato quello
in cui essa definisce la correlazione dei messaggi con le diverse istanze di
processo e risolve il problema delle \emph{multiple start activity}. In
particolare la semantica di Blite specifica tale comportamento in maniera molto
brillante e con un formalismo estremamente sintetico ed efficace, ma che mal
si presta a guidare lo sviluppo del software. 

In un'implementazione che usa il \emph{multithreading} per realizzare il
parallelismo, non ha senso parlare di più istanze di processo che eseguono
contemporaneamente la ricezione sulla medesima porta, per cui diventa inutile
valutare una priorità nell'attribuzione dei messaggi alle diverse istanze.

Di fatto un'istanza di processo, nel momento in cui si trova nella condizione
di poter consumare un messaggio, può stabilire se questo è ad essa
correlato semplicemente valutando la funzione booleana $\x{corr}(\xcorr,
\xsigma, \xx, \xv)$ introdotta nella Sezione \ref{sec:semcor}.

% $$
% \begin{array}{c}
% \x{corr}(\xcorr, \xsigma, \xx, \xv	) =
% \left\{
% \begin{array}{l@{\hspace{2ex}}l}
% \\[-.50cm]
% false & \textrm{se}\ \xx \in \xcorr \, \wedge \, \xx \in \xdom{\xsigma} 
% \, \wedge \, \xv \neq \xsigma(\xx)
% \\[-.05cm] true & \textrm{altrimenti} \\
% \end{array}
% \right.
% \\[.7cm]
% \x{corr}(\xcorr, \xsigma, \arr{}, \arr{}) =
% true
% \\[.7cm]
% \prooftree
% \x{corr}(\xcorr, \xsigma, \xx_1, \xv_1) = b'
% \quad
% \x{corr}(\xcorr, \xsigma, \bar{\xx}_2, \bar{\xv}_2) = b''
% \justifies \
% \x{corr}(\xcorr, \xsigma, (\xx_1,\bar{\xx}_2), (\xv_1,\bar{\xv}_2)) =
% b' \wedge b''
% \endprooftree
% \\[.7cm]
% \end{array}
% $$


Se dal punto di vista dell'attribuzione dei messaggi alle istanze il problema
può considerarsi risolto, rimane il fatto di distinguere se un
messaggio in arrivo debba produrre o meno una nuova istanza. Il
\icode{ProcessManager} deve di fatto prendere questa decisione al momento della
ricezione in base alle informazioni di cui dispone in quel momento. 

In generale si potrebbe pensare di risolvere il problema semplicemente a livello
sintattico\footnote{La soluzione può sembrare ingenua, ma per esempio è ciò che
di fatto fa Oracle Process Manager.}, rendendo distinguibili le porte di
ricezione su cui vengono create le istanze (\emph{create port}). \`E ovvio che
questa tecnica non permette di realizzare le multiple start activity, in cui una
porta è contemporaneamente di creazione e di possibile correlazione. Per
realizzare le multiple start activity è necessario implementare un meccanismo di
notifica da parte delle start activity di ricezione nei confronti delle istanze
di processo e di quest'ultime nei confronti del \icode{ProcessManager}. Questo
flusso d'informazione e l'utilizzo opportuno dei metodi per la sincronizzazione
dei thread (si veda la Sezione \ref{sec:comevent} e in particolare il codice
presentato a pagina \pageref{cod:wait}) permette di realizzare il comportamento
specificato dalla semantica di Blite, in particolare la correlazione e le
multiple start activity.

% Con questa informazione il \icode{Process Manager} può sapere se esiste o meno
% un'istanza in grado di correlare con un messaggio in arrivo ad una
% porta\footnote{Ovviamente la correlazione è solo potenziale in quanto non vi è
% la garanzia che essa avvenga certamente, l'istanza nella sua evoluzione può
% anche non arrivare mai a consumare il messaggio correlato.}, e in particolare
% per le multiple start activity può utilizzare tale informazione per distinguere se trattare la porta come di creazione o di correlazione.

\`E chiaro che la semantica attuale di Blite specifica alla perfezione il
comportamento voluto, ma crea un notevole scarto tra la sfera teorica e quella
tecnologica che rende difficile capire quanto l'implementazione realizzi del
tutto tale comportamento. Inoltre diversi processi di sviluppo possono attuare
strategie di implementazione tra loro completamente diversi, aumentando di fatto
la probabilità di difformità.

In tal senso speriamo che questa esperienza e queste osservazioni
aiutino ad affiancare alla semantica attuale una versione, in cui i formalismi e
le strategie di specifica siano più in linea con le necessità di sviluppo che
abbiamo incontrato e che le soluzioni ideate possano in qualche modo
essere d'ispirazione.
  
\section{Sviluppi futuri}

Per ciò che concerne lo sviluppo software, le attività da svolgere sono
essenzialmente due:

\begin{itemize}
  \item Sviluppare diversi Environment per l'Engine di Blite per realizzare
  diverse strategie di comunicazione.
  \item Migliorare il formalismo e la tecnologia grafica usata per la
  rappresentazione delle istanze in Blide.
\end{itemize} 

Per quanto riguarda il primo punto, come già più volte detto, le possibilità
sono molteplici. 

Un primo passo molto semplice potrebbe essere quello di creare un Environment
che supporti la comunicazione remota fra programmi Blite. In questo caso si
potrebbe utilizzare una tecnologia nativa per implementare la comunicazione. Per
esempio, utilizzando le socket e la Java Object Serialization si potrebbe di
fatto scambiare in rete gli oggetti attualmente utilizzati dal Local
Environment e avere quindi la possibilità di
distribuire i Deployment Blite su diversi nodi di rete. Ovviamente per poter
fare questo bisogna che ai nomi dei servizi sia associato un indirizzo di rete.

Questa associazione può essere fatta direttamente nel file di definizione di
Blite, in pratica la sintassi stessa delle invoke potrebbe esplicitare
l'indirizzo dell'host a cui è diretto il messaggio.

\begin{verbatim}
    inv <"hostserver.dom/serviceName"> operation (params) 
\end{verbatim}

Alternativamente, per non appesantire troppo la struttura del codice
(specialmente nel caso di partner link bidirezionali), potrebbe essere prevista
una sezione a parte in cui si va a legare un nome simbolico utilizzato nelle invoke con un
indirizzo fisico.

Sicuramente molto più interessante sarebbe poter far dialogare i nostri programmi
Blite con altri tipi di servizi definiti con linguaggi e tecnologie diverse,
primi fra tutti i Web Service. Per far questo la cosa fondamentale è creare
un meccanismo che relazioni il codice Blite alle definizioni WSDL. In pratica
serve, da una parte ricavare una definizione dell'interfaccia del processo
Blite e dall'altra associare le operazioni d'invocazione ad alcune definizioni di
servizi preesistenti.

Si potrebbe pensare di realizzare un tool \texttt{blite2WSDL} che, preso in
input un file \texttt{.blt}, esegua le operazioni necessarie ad impostare un
legame fra il programma e le definizioni WSDL.

Il processo di creazione dell'interfaccia può essere fatto, per esempio,
combinando un'attività utente con un processo automatico. 
Tramite un'analisi del codice Blite si potrebbe pensare di creare uno
scheletro per la definizione WSDL, che l'utente può successivamente
raffinare, andando per esempio ad esplicitare: i tipi XSD delle parti dei
messaggi, alcuni riferimenti dei namespace o alcuni dettagli del binding
WSDL/SOAP. In questo modo non ci sarebbe ovviamente nessun controllo statico che
i messaggi ricevuti siano usati, all'interno del codice Blite, in maniera
conforme con il tipo esplicitato nel contratto, ma questo concorda con la gestione
attuale, in cui a runtime si attua una conversione implicita dei tipi o, se in
ultima analisi nessuna conversione è applicabile, si genera un errore. 

L'associazione delle operazioni di output con le definizioni WSDL dei servizi
partner può essere fatta inserendo alcune meta-annotazioni nel codice Blite,
associando, per esempio i nomi dei servizi alla coppia
$\langle$service:name/port:name$\rangle$ di una definizione WSDL che deve
essere disponibile a runtime.

Il tool \texttt{blite2WSDL} nella sua esecuzione potrebbe anche fare alcuni
controlli sulla conformità della struttura sintattica fra l'operazione Blite di
invocazione e la definizione WSDL associata.

Una volta che si dispone dei file WSDL e delle associazioni fra questi e le
operazioni di comunicazione di Blite, si può pensare di generare un tool
(\texttt{blite2Java}) in grado di produrre il codice Java, che a
runtime andrà ad eseguire l'effettiva integrazione fra il framework per Web
Service utilizzato (ad esempio uno fra JAX-WS \cite{JAXWS}, Axis2 \cite{AXIS},
CXF \cite{CXF}, ecc) e l'interfaccia \icode{EngineChannel}. Il nostro tool
dovrà essere utilizzato in sinergia con il tool del framework scelto che produce
il codice Java a partire dalle definizioni WSDL e dovrà attuare un'integrazione
di tale codice.

Probabilmente in fase di invocazione è anche possibile evitare la generazione
statica del codice e utilizzare le API che framework come JAX-WS o WSIF mettono
a disposizione per l'invocazione dinamica di Web Service.

Un approccio totalmente dinamico in fase di ricezione risulta anche possibile
limitandosi ad una versione specifica del protocollo SOAP.

Probabilmente risulta più facile realizzare un Environment capace di dialogare
con un Enterprise Service Bus basato su JBI \cite{JBI}, in quanto tale standard
è stato ideato appositamente per l'integrazione di \emph{Service Engine} e quindi
esistono, oltre ad una serie di API appositamente studiate, una buona
documentazione e diversi esempi su come realizzare tale l'integrazione
Ad esempio il progetto \emph{Open nESB} \cite{OPENESB} può essere un valido
punto di partenza per iniziare a sviluppare componenti software basati sullo
standard JBI.
\\

Per quanto riguarda Blide l'attività potrebbe concentrarsi sull'apportare
migliorie al formalismo grafico utilizzato per rappresentare l'esecuzione delle
istanze e a potenziarne l'implementazione, nel senso di fornire un maggiore
grado di interattività. Si potrebbe dare all'utente la possibilità di spostare
le varie istanze nel \emph{Monitor View} al fine di ottenere una
rappresentazione ottimale o di posizionare il mouse sulle diverse attività e
ricavare da queste informazioni sullo stato dell'esecuzione.





